Bump mls-rs to the germ-integration pin, and keep APP_DATA_UPDATE pathless - #122

Moves the mls-rs pin from ec69dc25 (germ-shadow-safe-exporter) to b43703fb (germ-integration). Five workspace dependency entries plus the [patch.crates-io] redirect move together.

Also drops serde entirely — the mls-rs feature and the unused [workspace.dependencies] entry. Nothing consumes either: no .rs file references serde and no member crate declares it. mls-rs's serde derives are cfg_attr-attached and never participate in MlsEncode/MlsDecode, so removing the feature cannot move a byte of the stored format; archiving goes through the crate's own wire structs, untouched here.

The fork's main was resynced with upstream awslabs/mls-rs (now 09761fa, +7 commits) and the Germ changes recomposed on top. The new pin adds nothing beyond that recomposition: the crypto providers, a build fix that had been riding the old pin outside any feature branch, the Safe Extensions exporter tree, and attachment CEK derivation. See FORK.md.

The one behavioural change

awslabs/mls-rs#364 added MlsRules::custom_proposal_requires_update_path, documented as "The default implementation returns true (conservative: always require a path)." TwoMlsRules could not override a method that did not exist yet, so after the bump APP_DATA_UPDATE — an attestation that changes no group membership — began forcing an updatePath.

On the PQ half that means an ML-KEM updatePath rides a commit that must be pathless. test_bind_pq_commit_is_pathless caught it: the bind commit grew to 4042 B against a 1088 B bound (one ML-KEM-768 ciphertext).

TwoMlsRules now overrides the hook to false. RFC 9420 §12.4 leaves the path at the committer's discretion for a proposal that does not change membership, so this restores the behaviour apq was written against rather than introducing a policy. Where a path is wanted — the FULL commit discharging an owed bind on the classical half — commit_options still pins it explicitly, which is where that decision belongs.

I isolated this before fixing it: the failure reproduces at the exporter-tree tip without any attachment work, and does not reproduce on the old pin. So it comes from the upstream resync, not from the Germ changes layered on it.

Archive compatibility

No change. Group state written by the old pin still loads:

• Every type deriving MlsEncode/MlsDecode was diffed between the two pins — 467 definitions, field order and cfg gates included. The only difference is a new encode-only label struct that is never persisted. Enum discriminants are identical.
• germ-integration was reconstructed after this PR was opened, so every commit id changed. The library tree is byte-identical between the old and new pin — the delta is the CI workflow and FORK.md only — so the verification below still applies.
• Real Snapshot and PriorEpoch blobs captured from the old pin load on the new one, and are pinned as fixtures in the mls-rs repo. The reverse direction (rollback) was checked too.
• EPOCH_RETENTION = 3 in apq/src/storage.rs is unchanged and still bounds how far epoch history reaches back.

Testing

apq 51 + 8 + 9 · two-mls-pq 307 with cryptokit · cargo fmt --all --check · taplo fmt --check · cargo clippy -p apq --all-targets -- -D warnings. The upstream pin itself is CI-green on the fork across ubuntu-latest, macos-26, each-feature, no_std/thumbv6m, mls_build_async, lint and audit.

Not verified locally: the awslc feature path (aws-lc needs go/ninja/nasm on this machine) and the Swift/iOS build. Given the regression above came from a subtle upstream behaviour change, both are worth a look before this ships.